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RttMARKS/ARftUMENTS 



Reconsideration of the rejections set forth in the Final Office Action dated March 7, 
2005, and the Advisory Action dated June 1, 2005, is respectfully requested. Claims 1-28 are 
have been rejected. Claims 29 and 30 have been added. As such, claims 1-30 are currently 
pending. 

It is noted that in the Advisory Action dated June 1, 2005, the Examiner has indicated that 
the Amendment filed by the Applicant on May 6, 2005 has been entered. 

Claims 1 , 1 0, 1 2, 14, 25, and 27 have each been amended to recite selecting a second 
protocol stack from a plurality of protocol stacks. Support for these amendments may be found 
in the Specification, as for example on page 8 at lines 17-18. 

New claim 29 recites that selecting the second protocol stack to be unloaded includes at 
least one of determining when the second protocol stack is in use, detennining an amount of 
memory the second protocol stack needs to be loaded, and determining whether the second 
protocol stack is compatible with the first protocol stack. Support for this new claim may be 
found in the Specification, e.g., on page 8 at lines 1 8-20. New claim 30 recites that a second 
protocol stack is not in use when detemiining whether the first protocol stack can be loaded. 
Support for this new claim may be found in the Specification, as for example on page 8 at lines 
16-20. 

Specification 

As previously stated in the Amendment filed May 6, 2005, it is not entirely clear to the 
Applicant why, in the Final Office Action dated March 7, 2005, the Examiner reminded the 
Applicant of the proper content of an abstract of the disclosure. On page 2 of the Final Office 
Action, the Examiner italicized the statement that reads "The abstract should not refer to 
purported merits or speculative applications of the invention and should not compare the 
invention with the prior art." 
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It is believed that since the Examiner entered the Amendment filed May 6, 2005, the 
Examiner has accepted the amendments to the Abstract that were presented in that Amendment. 
Those amendments to the Abstract are, hence, believed to overcome the Examiner's objections t 
the Abstract. 



Claims 1-3, 7-10, 12, 14-18, 22-25, and 27 have been rejected under 35 U.S.C. § 102(b) 
as being anticipated by U.S. Patent No. 5,640,394, issued June 17, 1997 to Schrier et al. 
(hereinafter "Schrier"). Claims 1 1, 13, 26, and 28 have been rejected under 35 U.S.C. § 1 03(a) 
as being unpatentable over Schrier. Claims 4-6 and 19-21 have been rejected under 35 U.S.C § 
103(a) as being unpatentable over Schrier in view of U,S, Patent No. 6,032,154, issued Februaiy 
29, 2000 to Coleman et al. (hereinafter "Coleman"). 

L Independent Claims 7, 10, )2 t and their respective dependents 

Independent claim 1 recites a method which includes receiving a message to load a first 
protocol stack, and determining whether the first protocol stack can be loaded. If the first 
protocol stack cannot be initially loaded, then the second protocol stack is unloaded. After the 
second protocol stack is unloaded, the first protocol stack is loaded. Claim 1 has been amended 
to recite thai the second protocol stack is selected from a plurality of protocol stacks. The 
plurality of protocol stacks does not include the first protocol stack- 
It is noted that the Applicant's have amended claim 1 in an effort to expedite the 
prosecution of the instant application. The amendment made to claim 1 is not to be construed by 
the Examiner to be an agreement with the Examiner's rejection of claim 1 , as the Applicant 
believes that claim 1, as originally filed, is allowable over the cited art. The Applicant reserves 
the right to reintroduce claim 1 as originally filed, or claims of a similar scope, in future 
continuing applications. 
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Schrier does not teach or suggest selecting a second protocol stack from a plurality of 
protocol stacks that does not include a first protocol stack, as required by claim 1. It is 
respectfully submitted that Schrier teaches only of a protected mode protocol stack and a real 
mode protocol stack (e.g., Schrier, column 4, lines 29-41)- The real mode protocol stack appears 
to be automatically selected for "transferring communication responsibilities" when the protected 
mode protocol stack is to be run. In fact, Schrier specifically teaches of two protocol stacks 
(Schrier, column 4, lines 29-34), one of which is the real mode protocol stack and the other of 
which is the protected mode protocol stack- Hence, Schrier does not teach of selecting a second 
protocol stack from a plurality of protocol stacks (e.g., a plurality of protocol stacks that does got 
include the protocol stack that is to be loaded). The plurality of protocol stacks that does not 
include a first protocol stack. Therefore, claim 1 is believed to be allowable for at least this 
reason. 

The Applicant respectfully disagrees with the Examiner's statement on page 10 of the 
Final Office Action dated March 7, 2005 which reads "Applicant also asserts that the Schrier 
reference is not able to differentiate between the two loaded protocol stacks. However, the 
reference teaches 'real mode' and 'protected mode* protocol stacks." At lines 29-34 of column 
4, Schrier states: 

"As discussed above, once a real mode protocol stack has been loaded 
and is operating, it is not possible to run a subsequent protected mode 
version of a protocol stack which implements the same protocol 
because the stack manager is not able to differentiate between the 
two protocol stacks? [emphasis added] 

It is respectfully submitted that Schrier teaches of not being able to differentiate between two 
protocol stacks (a real mode protocol stack and a protected mode version of the protocol stack). 
As stated in the passage above, the stack manager of Schrier is not able to differentiate between 
two protocol stacks. A careful reading of the above-recited passage makes it clear that the two 
protocol stacks that the stack manager is unable to differentiate are a real mode protocol stack 
and a protected mode protocol stack. The Examiner has even cited the above-recited passage in 
his rejection of claim 1 . Hence, the assertion of the Applicant is based on the direct teachings of 
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Schrier. It is Schrier that makes it clear that a stack manager is not able to differentiate between a 
real mode protocol stack and a protected mode protocol stack. 

Schrier is generally directed to methods of operating two protocol stacks that implement 
the same protocol. The reference describes that this situation can occur if the same protocol is 
implemented in one protocol stack in real mode for MS-DOS and one protocol stack for 
protected mode of WINDOWS (Schrier, column 3 at lines 57-63). Schrier describes that a stack 
manager is unable to differentiate which protocol stack to use (Schrier, column 4 at lines 29-34). 
It appeals that both protocol stacks of Schrier are loaded, otherwise there would be no issue with 
two protocol stacks that implement the same protocol, Le., Schrier teaches that a first protocol 
stack and a second protocol stack are such that b oth can be loaded at the same time. 

As taught by Schrier, when a second protocol stack (e.g., the real mode protocol stack for 
the protocol) is loaded and operating, it is not possible to run a first protocol stack (e.g. , the 
protected mode protocol stack for the protocol) because a stack manager cannot differentiate 
between the first and second pnrtocol stacks (Schrier, column 4 at lines 29-34). Schrier teaches 
that a solution would be to terminate the second protocol stack (e.g., the real mode protocol stack 
for the protocol) and transfer communication responsibilities using the second protocol stack to 
the first protocol stack (e.g., the protected mode protocol stack for the protocol) (Schrier, column 
4 at lines 34-37). Schrier discloses thai such a solution is tremendously difficult if not, as a 
practical matter, impossible. 

In the passages cited by the Examiner in the Final Office Action dated March 7, 2005 as 
anticipating claim 1 , Schrier addresses the problem of a stack manager not able to differentiate 
between two loaded protocol stacks. Schrier does not appear to teach of receiving a message to 
load a first protocol stack. Schrier appears to suggest recei ving a request to run a protected mode 
version after a real mode is operating, but does not teach or even suggest receiving a message to 
load the first protocol stack . There is also no teaching in Schrier of determining whether the first 
protocol stack can be loaded In the Advisory Action dated June 1 , 2005 f the Examiner cites the 
following passage from Schrier, which may be found in column 3 at lines 8-18: 
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"The loading of the various compatible protocol stacks is 
supervised by the network driver's stack manager which constructs 
and stores the record necessary to bind each protocol stack to the 
single driver. Following the steps of loading and binding each 
protocol stack, client applications may begin to communicate with 
the network using the bound protocols. To send data to the 
network, an application will pass the data to be transmitted to a 
particular protocol stack. The protocol stack implements the 
protocol and then passes the resulting packet to the generic 
interface of the driver." 

This passage of Schrier appears only to teach that applications may begin to communicate after a 
protocol $tack is loaded, and that the loading of protocol stacks i$ supervised. It is not clear to 
the Applicant why the Examiner believes that this passage teaches of determining whether a first 
protocol stack can be loaded. There is no teaching in this passage, or any other passage in 
Schrier, of determining w hether a protocol stack can be loaded. 

As discussed above, Schrier appears to teach that two protocol stacks may both be loaded 
at the same time. The stack manager of Schrier is not able to differentiate between two loaded 
protocol stacks, and, therefore, must transfer communications responsibilities for applications 
onto a single loaded protocol stack. There ts no determination of whether a protocol stack can be 
loaded, as both protocol stacks taught by Schrier are loaded, and the issue addressed by Schrier 
has to do with switching from a real mode of operation (which uses a real mode protocol stack) 
to a protected mode of operation (which uses a protected mode protocol stack). 

Schrier teaches, as discussed above, of terminating a second p rotocol stack and then 
transferring responsibilities of applications using the second prot ocol stack to a first protocol 
stack when a protected mode version of the first protocol stack is to be run (Schrier, column 4 at 
lines 24-27). It is respectfully submitted that transferring responsibilities of applications to a 
different protocol stack when the different protocol stack is to be run is not the same as, and does 
not suggest, receiving a message to load a first protocol stack, determining whether the first 
protocol stack can be loaded, and unloading the second protocol stack if the first protocol stack 
cannot be initially loaded. Accordingly, claim 1 is believed to be allowable for at least the 
reasons set forth. 
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Claims 2-9, 29, and 30 each depend either directly or indirectly from claim 1 and are, 
therefore, each believed to be allowable over the cited art for at least the reasons set forth with 
respect to claim 1 . Each of these dependent claims recites additional limitations which, when 
considered in light of claim 1 , are believed to further distinguish the claimed invention over cited 
art. By way of example, claim 29 recites that selecting a second protocol stack from a plurality 
of protocol stacks includes at least one of determining when the second protocol stack is in use, 
determining an amount of memory the second protocol stack needs to be loaded, and determining 
whether the second protocol stack is compatible with the first protocol stack. In addition to not 
teaching of selecting a second protocol from among a plurality of protocol stacks, Scbrier does 
not teach of selecting any protocol stack based on determining whether the stack is in use, the 
amount of memory the stack needs to be loaded, or compatibility. As such, claim 29 is also 
believed to be allowable over Schrier for at least this additional reason. 

Independent claims 10 and 12, as amended, recite similar limitations as recited in 
amended claim 1. Therefore, claims 10, 12, and their dependents are each believed to be 
allowable over the cited art for at least the reasons set forth above with respect to claim 1 . 

2. Independent Claims 14 t 25 t 27, and their respective dependents 

Amended independent claim 14 recites a method which includes sending a message from 
a first node to a second node to load a first protocol stack- The method also includes the second 
node receiving the message to load the first protocol stack, the second node determining whether 
the first protocol stack can be loaded, the second node selecting a second protocol stack from a 
plurality of protocol stacks, and the second node unloading a second protocol stack if the first 
protocol stack cannot be initially loaded on the second node. Finally, the method includes the 
second node loading the first protocol stack. 

Claim 14 recites similar limitations as recited in claim 1- As such, claim 14 is believed to 
be allowable over Schrier for at least the reasons set forth above with respect to claim 1 . Like 
claim 1, clai m 1 4 has been amended purely to expedite prosecution. The Applicants are of the 
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belief that claim 14, as originally filed, is allowable over the cited art. The Applicants hereby 
reserve the right to reintroduce claim 14, as well as claims of a similar scope, in a future 
continuing patent application. 

On page 5 of the Final Office Action dated March 7, 2005, the Examiner has stated that 
claim 14 is a variation of claim 1 . While this may be the case, claim 14 also recites additional 
limitations which are neither taught nor suggested by Schrier. By way of example, claim 14 
recites that a first node sends a message to a second node to load a first protocol stack. The 
Applicant respectfully submits that there is no teaching in Schrier of first and second nodes, let 
alone a first node that sends a message to a second node to load a first protocol stack. The 
Examiner has not addressed the limitations of having first and second nodes. As Schrier does not 
appear to teach the limitation of a first node sending a message to a second node (e.g., a message 
to load a first protocol stack), claim 14 is believed to be allowable over Schrier for at least this 
reason as well. 

Claims 15-24 each depend either directly or indirectly from independent claim 1 4 and, 
hence, are each believed to be allowable over the cited art for at least the reasons set forth above 
with respect to claim 14. Each of these dependent claims recites additional limitations which, 
when considered in light of the limitations in claim 14, are believed to further distinguish the 
claimed invention over the art of record. For example, claim 15 requires that first and second 
nodes are in different devices. Schrier does not appear to teach of one device sending a message 
to a second device to load a first protocol stack* As Schrier does not appear to teach of nodes 
being in different devices, claim 15 is believed to be allowable for this reason as well 

Amended independent claims 25 and 27 recite similar limitations as recited in amended 
claim 14. Therefore, claims 25, 27, and their dependents are all believed to be allowable over the 
cited art for at least the reasons set forth above with respect to claim 14. 
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Conclusion 

For at least the foregoing reasons, the Applicant believes all the pending claims are in 
condition for allowance and should be passed to issue. If the Examiner feels that a telephone 
conference would in any way expedite the prosecution of the application, please do not hesitate 
to call the undersigned at (650) 694-5339. 



Date: 




Respectfully submitted, 



SIEMENS CORPORATION 
Customer Number: 28524 
Intellectual Property Department 
170 Wood Avenue South 
Iselin, New Jersey 08830 
ATTENTION: Elsa Keller, IP 
Department 

Telephone: (732) 321-3026 




David D. Chung 
Registration No. 38,409 
Attorney for Applicants 
Tel: 650-694-5339 
Fax: 650-968-4517 
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